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(57) Abstract 

The present invention comprises a system and method for a customer and merchant to perform an on-line, and in some cases, 
reaMime financial trareaction fiom a personal ccmiputer or similar |»occssing terminal (10) over a public access communications network 
(II) utilizing a unrversally acceptable electronic financial transaction instruction that debits a customer's selected account and notifies a 
merchant that a credit is due or forthcoming from a service provider. Tbc financial transaction instruction is provided in a secured formal 
for transactions sent over the pukrfic access communications network (11), which is external from any other conventional open or closed 
communications channels used for performing financial transactions. 
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5 System and Use for Correspondent Banking 

Cross-Reference to Related Applications 

Reference and priority to provisional application no, 60/098,196, filed 
August 27, 1 998 tilled, "System for Merchant Function Assumption of Internet 

1 0 Checking and/or Savings Account Transactions" and application no. 09/237,739 
filed January 28, 1999 titled, "POS at Home - System and Method for Accessing 
Banking Account Funds for Internet Transaction" are hereby claimed and the 
entirety of the subject matter of each pending application is incorporated by 
reference. Further, reference is made to and application no. 09/ , filed 

1 5 August 27, 1 999 title, "System for Merchant Function Assumption of Internet 
Checking and/or Savings Account Transactions," the entirety of which is hereby 
incorporated by reference. Finally, the subject matter of provisional application 
no. 60/138,607 filed June 1 1, 1999 titled, "Certificate-Based Credit Account^' is 
hereby incorporated by reference. 

20 

Field of the Invention 

The present invention relates to banking systems and Internet transacticHis, 
and more particularly, to a system that allows a customers, merchants, and their 
respective financial institutions to perform Internet transactions. 

25 

Background 

SUBSTftUTE SHEET IRULE 2B) 
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With the increasing commercialization of the Internet, methods of 
performing payment transactions are becoming well known and new payment 
methods are desired. In an effort to expand the available sources of payment, 
methods have been developed to utilize checking account funds to perform 

Internet transactions. 

A first conventional method uses "electronic checks** to perform 
transactions. One example of such an elecu^onic check is the "e-check" process 
established by the Financial Services Technology Consortium (FSTC). Prior an 
Figure la illustrates the system and flow of information used in performing an e- 
check Internet transaction. In order to participate in an e-check Internet transaction, 
all of the participants possess the enabling software. Utilizing a processor with a 
modem 10, the customer sends customer payment instiiictions 1 over the Internet 11 
to a merchant's Internet terminal 12. The merchant's tenninal 12 attaches the 
merchant's payment instructions and forms a data message having both the 
customer's and the merchant's payment instructions 2. The data message 2 is 
transmitted over the Inlcmel to the merchant's financial institution server 18 where 
the server reads the data message and begins settlement procedures with the 
customer's financial institution 16 over the automated clearing house (ACH) 
network or electronic check processing (ECP) network using ACH or EC? 
formatted instructiwis 3. Since the merchant's financial institution is initiating the 
ACH or ECP process, the ACH or ECP instructions 3 are in the form of an ACH 
or ECP debit request. 
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There arc a number of problems, however, associated with current electronic 
check methods. For example, there is a delay between the time that the merchant is 
notified that the e-check has been renimed. This delay may be three or more days. As 
a result, the merchant typically must wait a number of days to find out whether or not 
the funds are good, thereby delaying fulfillment of the order. As such, utilizing this 
type of electronic check creates uncertainty for the merchant, as they are unsure if the 
electronic check will be paid. Thus, despite the transaction having the appearance to 
the customer of being on-line and real-time, it takes several days for the merchant's 
account to be charged and for the transaction to be completely processed. 

Even taking into account the delays associated with the e-check payment 
process, it is still an extremely useful and viable payment method for many types of 
goods and/or services but, for a consumer to be able to use this type of e-check, the 
consumer must be a member of a financial institution or financial institution that 
offers this service. Over the next 5 to 1 0 years, however, only a few dozen financial 
institutions are estimated to participate in issuing electronic checks. Because of this 
limited participation^ the majority of customers vdll not have access to e-checks from 
the financial institution with whom they have an account relationship. Thus, in turn, 
the number of customers that a merchant can attract and serve vnih an electronic 
check is limited. 

Additionally, for example, not only must the customer be a member of a . 
participating financial institution, but the merchant must set up procedures for these 
types of transactions to deal with the limited number of participating financial 
institutions. Due to the limited number of customers who would utilize this payment 
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5 method, a merchant may be discouraged from expending the time and money to 

« 

p^abiish such a system. 

A second conventional payment system and method as shown in Figure lb 
begins with the customer modem JO sending customer payment instructions 1 over 
the Internet 11 to a merchant's Internet terminal 12. The merchant's tenninal 12 
10 attaches the merchant's payment instructions and forms a data message having both 
the customer's and the merchant's payment instructions 2. The data message 2 is 
transmitted over the Internet to the customer's financial institution server 16 where 
the ser\'er reads the data message and begins settlement procedures with the 
merchant's financial institution 18 over the automated clearing house (ACH) 
15 network using ACH formatted instructions 3. Since the customer's financial 
institution is initiating the ACH or ECP process, the ACH instructions 3 are in the 
form of an ACH credit An ACH credit is guaranteed since it is issued by the 
authorizing financial institution. While this method solves the problem of on-line 
notification to the merchant that the customer has the funds, the method still requires 
20 that at least the customer, mo^chant and the customer's financial institution be 
equipped to handle Internet formatted transactions and instructions. This is extremely 
costly due the stringent hardware and software requirements. 

In a third conventional payment system, the customer, likely for security 
reasons, does not choose to have the customer payment instructions go through the 
25 merchant. In Figure Ic, the customer modem 10 directs the customer payment 
instructions to the customer financial institution 16 via the Internet 11. At this point, 
the customer's financial institution may hide or encrypt the customer's financial 
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5 infonnation such that it is recognizable only to them or the customer's financial 
institution removes the customer's infonnation altogether. Along with authorization, 
the customer s financial institution sends a data message 5 to the merchant terminal 
via the Internet. After receipl of the data message 5 the merchant may currently 
process the payment as shown in Figures la or lb. As discussed with reference to . 
10 the conventional payment methods described above, this payment flow requires 
that at least the customer, the merchant, and the customer's financial institution be 
equip()ed to receive and process Internet formatted transaction requests. 

Currently, there is a need for low-cost access to various individual and 
business accounts held by customers and merchants at multiple financial institutions, 
15 to perform fmancial transactions over the Internet. Most customers access the Internet 
from remote locations, such as personal computers at home or at a business. Further, 
many fmancial institutions, though accessible through networks such as automated 
teller machine (ATM), ACH, ECP, are not accessible on-line and in real-time by 
Internet customers and/or merchants wishing to utilize their accounts held within the 
20 financial institutions. Finally, the time and expense necessary to put an on-line, real- 
time payment system into place is currently too great for the majority of financial 
institutions. 

Summary of the Invention 

25 Generally, the present invention comprises a system and method for a 

customer and merchant to perform an on-line, and in some cases, real-time financial 
transaction from a personal computer or similar processing terminal over a public 
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5 access communications network utilizing a universally acceptable electronic financial 
transaction instruction that debits a customer's selected account and notifies a 
merchant that a credit , is due or forthcoming. The financial transaction instruction is 
provided in a secured format for transactions sent over the public access 
communications network, which is external fi^om any other conventional open or 
1 0 closed coiiununication charmels used for performing financial transactions. 

The system arKl method of the present invention advantageously does not 
require that there be a traditional financial institution relationship between the 
customer, the merchant, and their respective service providers/correspondent financial 
institutions facilitating the on-line financial transactions. Further, the system 
15 beneficially does not require the financial institution used by the customer and/or the 
fisiaiKial institution used by the merchant to have the capability to perform financial 
transaction instructions over the Internet. Additionally, the system is compatible vnth 
current financial transaction systems, thus making the present financial transaction 
instruction a universally acceptable on-line financial payment scenario. 
20 Acctnrding to a prefeixed embodiment^ a method of performing a financial 

transaction between a customer and a merchant, com{»rises creating ctistomcr payment 
instructions comprising encrypted, electronic representations of a customs 
transacticHi amoimt, accotmt information, financial institution information and security 
information . The accotmt information identifies variotis payment accounts, e.g., 
25 checking, savings, money market, at the customer's financial institution and the 
security information may comprise a personal identification number associated with 
the. identified account information for authorizing its use in an on-line payment 
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5 transaction. The ciistomer payment instructions are protected by a first secure 
mechanism, such as an attached digital certificate including a digital signature. The 
digital signature or other authentication device of the customer provides verification 
of the identity of the customer and the integrity of the customer payment instruction. 
The customer payment instructions are electronically delivered to the merchant or in . 

10 some cases, the customer's financial institution, over a public access network like the 
Internet. 

Merchant payment instructions are appended to the customer payment 
instructions to create financial transaction instructions. The merchant payment 
instructions comprise merchant identification and merchant deposit account 
15 identification used in performing the transaction. The financial transaction 
instructions may be protected by a second secure mechanism, such as with encryption 
and/or by the digital signature of the merchant. The merchant's digital signature 
provides verification of the merchant's identity and of the integrity of the financial 
transaction instructions. A digital certificate of the merchant may be appended to the 
20 fmancial transaction instructions, where the merchant's digital certificate provides 
additional verification of the merchant's identity and the integrity of the financial 
transaction instructions. 

The financial transaction instructions are electronically delivered, such as over 
the Internet, to at least one service provider offering access to the Internet and other 
25 on-line communication channels and public access networks to perform the financial 
transaction. The service provider removes and refonnats the encrypted financial 
transaction instructions received via the Internet or comparable network and forms a 
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5 recognizable transaction request or message for the participating financial institutions. 
Reformatting the request or message comprises placing the Internet fmancial 
transaction request into a formal that is recognizable and acceptable to the 
participating fmancial institutions. These are formats which are deliverable over 
conventional networks or channels. The reformatted transaction requests or messages . 
10 are electronically delivered to the participating financial institutions through the 
appropriate network or channel. 

A non-exhaustive list of advantages provided by the foregoing system and 
method includes: reduction in the amount of equipment and hardware necessary 
for the facilitation of the payment transaction; increase in the efficiency of Internet 
1 5 payment methods; increase in the number of parties who may partake of Internet 
purchasing schemes; and reduction in cost associated with Internet payment 
schemes without compromising security. 

Brief Description of the Drawings 
20 In the drawing^: 

Figure 1 a is a first conventional payment system; 

Figure lb is a second ccHiventional payment system; 

Figure Ic is a second ccHiventional payment system; 

Figure 2 is a first payment system embodiment; 
25 Figure 3 is a second payment system embodiment; 

Figure 4 is a third paymerit system embodiment; 
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Figure 8 is a seventh payment system embodunent; 
Figure 9 is an eighth payment system embodiment; 
Rgure 10 is a ninth payment system embodiment; 
Figure 1 1 is a tenth payment system embodiment; 
Figure 12 is an eleventh payment system embodiment; 

* 

Figure 1 3 is a twelfth payment system embodiment; and 
Figure 14 is a thirteenth payment system embodiment; 

* ■ 

Description of the Preferred Embodiments 

The following preferred embodiments of the present invention require that 
at least the merchant and the customer be equipped with Internet payment 
instruction software including but not limited to encryption programs as well as 
digital certificates for identification and digital signature capability for confirming 
message integrity. Further, in a number of the preferred embodiments, one skilled 
in the art will recognize that all parties to the transaction must be equipped with 
some type of enabling software. Prior to discussing the particular payment flow 
system and mediod embodiments, the following provides an explanaticm of the 
possible sources of the software and certificates and the subject matter included 
therein. 

In the specific embodiments that follow, the customers and the merchants 
are furnished with digital certificates and software enabling than to transact over 
the Internet. These enabling components may be supplied by customer's and 
merchant's respective financial institutions or the service providers acting in lieu 

SUBSmrUTE SHEET (RULE 26) 
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5 Figure 5 is a fourth payment system embodiment; 
Figure 6 is a fifth payment system embodiment; 
Figure 7 is a sixth payrnent system embodiment; 
Figure 8 is a seventh payment system embodiment; 
Figure 9 is an eighth payment system embodiment; 

1 0 Figure 1 0 is a ninth payment system embodiment; 
Figure 1 1 is a tenth payment system embodiment; 
Figure 12 is an eleventh payment system embodiment; 
Figure 13 is a twelfth payment system embodiment; and 
Figure 14 is a thirteenth payment system embodiment; 



15 



Description of the Preferred Embodiments 

The following preferred embodiments of the prKcnl invention require that 
at least the merchant and the customer be equipped with Internet payment 
instrucUon software including but not limited to encryption programs as well as 
20 digital certificates for identification and digital signature capability for confirming 
message integrity. Further, in a number of the preferred embodiments, one skiUed 
the art will recognize that all parties to the transaction must be equipped with 



m 



some 



type of enabling software. Prior to discussing the particular payment flow 
system and method embodiments, the followmg provides an explanation of the 
25 possible sources of the software and certificates and the subject matter included 
therein. 
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In the specific embodiments that follow, the customers and the merchants 
are furnished with digital certificates and software enabling them to transact over 
the Internet, These enabling components may be supphed by customer's and 
merchant's respective financial institutions or the service providers acting in lieu 
of the customer and merchant financial institutions. In the latter case, the 
necessary customer and customer*s financial institution information is supplied by 
the customer's financial institution for facilitating a payment out of the funds in 
the customer's account(s) with the customer's financial institution and similarly, 
the merchant and merchant's financial institution information is supplied by the 
merchant's financial institution for facilitating a credit to the merchant's account. 

The customer information includes at least payment account mformation 
and other identifying information that may include name» address, social security 
number, and e-niail address/URL. The customer's financial institution 
information includes at least financial institution name and routing transit number. 
Either the customer's fmancial institution or the customar's financial institution 
service provider (CFISP) or even an indepradent third party service provider thofi 
acts as a certificate authority and utilizes the customer and customer's financial 
institution information to cwnpose digital certificates that are.distibuted to the 
customers of the customer's financial institution. 

Similarly, the merchant's financial institution, MFISP, ot third-party 
service provider, collects all of the requisite merchant and merchant financial 
institution information so as to issue digital certificates containing the requisite 
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5 merchant and merchant financial institution information. All of the issued digital 
certificates may follow the X.509 standards for such certificates, recommended by 
the International Telecommunications Union. Digital certificates are generally 
known in the electronic communication industry as offering a measure of security 
to electronic transactions. As applied to a preferred embodiment of the present 
1 0 invention^ the digital certificates issued by the service provider, will autoriiatically 
attach to the payment order sent via the Internet by the customer and merchant 
upon the institution of the payment software for making an Internet purchase; 

In addition to the digital certificates, at least one of customer's financial 
institution, merchant's financial institution, CFISP, or MFISP must issue enabling 
1 5 payment software to participating customers and merchants. A preferred payment 
software package of the present invention includes programs/applications for 
retrieving necessary payment execution information and for creating data 
messages (e.g., e-mails. Hypertext Markup Language (HTML) pages) under a 
specially defined file type, a browser plug-in for use with known web browsers 
20 (e.g., Netscape® and Internet Explorer®) for recognizing and executing the newly 
defined files, a program for encrypting data messages, and optionally, the issued 
digital certificates. 

Embodiments of the present invention anticipate that both the ctistomer and 
the merchant vnll be creating data messages with the issued payment software. 
25 The data message program retrieves and compiles purchase order information 

from the customer's files, as necessary, for controlling payment transactions. The 
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5 purchase order information includes payment instructions, an assigned serial 
number, the customer's e-mail address and/or URL, the customer's digital 
signature, the customer's digital certificate (including the customer's account 
number(s) or other security methodology and the customer's financial institution 
routing/transit number), and if applicable, the CFlSP's data message address (e.g., 
1 0 e-mail address or URL). Additionally, the merchant's payment software 

program/application adds information to the customer's e-mail upon receipt, to 
facilitate the payment transaction. This additional information includes a 
reference number, the merchant's data message address, the merchant *s digital 
signature, the merchant's digital certificate (including merchant's account and 
1 5 financial institution information), and if applicable, the MFlSP's data message 
address. 

One skilled in the art will recognize thai the following preferred 
embodiments necessarily incorporate compatible, interactive enabling software in 
order to facilitate at least the Internet transactions between the participating 
20 parties. 

According to a first preferred embodiment of the present invention. Figure 
2 provide a system and method enabling a merchant's financial institution server 
18 via a merchant's financial institution service provider (MFlSP)/correspcMidenl 
financial institution server (hereafter "MFISP") 14 to allow a merchant terminal 
25 12 to perfonn public access network (e.g., Internet) (hereafter ''Internet") 
transactions. In the first preferred embodiment, the merchant's financial 

SUBSrmJTE SHEET (RULE 26) 
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insljtulion is not equipped to handle Inlemel payment transactions without 
employing a MFISP. The payment transaction flow of Figure 2, enables a 
merchant's financial institution to offer Internet payment services to its merchant 
customers. 

The Internet transaction is performed with an electronic payment vehicle 
that allows purchases, exchanges of value, and other payment information or order 
instructions to be sent over the Internet. In practice, a first embodiment of this 
invention enables a customer modem 10 to transmit customer payment instructions 
1 via the Internet 11 to a merchant terminal 12. The merchant terminal 12 adds the 
merchants payment instructions and transmits the data message containing both 
the customer and merchant payment instructions 2a (hereafter "data message") 
over the Internet 11 to the MFISP server 14. The MFISP 14 receives the data 
message 2a and reformats it into a deposit/credit message 2b that is recognizable 
and readable by the merchant's financial institution 18. This reformatting is 
necessary since the original data message 2a received by the MFISP is in an 
Internet or other public access network format, unreadable by the merchant's 
financial institution 18. The MFISP transmits the deposit message over a closed 
communication channel (CCC) or similar network which is established as a 
network for carrying deposit messages to financial institutions. The MFISP may 
elect to aggregate one cmt more payment instructions and send them to the 
merchant's financial institution according to specific time intervals and/or 
maximum number of aggregated deposit messages. 

SUBSTITUTE SHEET (RULE 26) 
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5 In an alternative sub-part of the first preferred embodiment, the CCC could 

be the Internet but the MFISP J 4b is still needed to formal the deposit message 
into a readable Internet format 2b wherein the originating Internet format 2a 
would be unrecognizable to the merchant's financial institution 18 without the re- 
formatting. 

1 0 The merchant' s financial institution 1 8 receives and pwrocesses the deposit 

message 2b and initiates settlement with the customer's financial institution server 
16 over the traditional ACH or ECP network or similar senlement channel with an 
ACH or electronic check processing (ECP) debit request 3a. Alternatively, the 
MFISP is capable of initialing the ACH or ECP debit request 3a as opposed to the 
15 merchant's financial institution. 

A second preferred embodiment of the present invention anticipates the 
situation where the customer's financial institution does not choose to have the 
customer's account number, or other sensitive information necessary for carrying 
out the payment transaction, presented to the merchant in any readable form. But, 
20 in the second preferred embodiment, the customer's financial institution does not 
have the necessary decryption tools for reading the encrypted, sensitive 
information. 

In Figure 3, utilizing a processor with a modem 10, the customer sends 
encrypted customer payment instructions 1 over the Internet 11 to a merchant's 
25 Internet tenninal 12. The merchant's tenminal 12 attaches the merchant's payment 
instructions and forms a data message having both the customer's and the merchant's 
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5 paymenl inslniclions 2. The data message 2 is transmitted over the Internet to the 
merchant's financial institution server 18 where the server decrypts all but the 
encrypted sensitive information and reads the data message and begins settlement 
procedures with the customer's fmanciaJ institution 16 over the automated clearing 
house (ACH) network or electronic check processing (ECP) netv/ork using an 
1 0 ACH or ECP (hereafter "ACff*) debit request 3a. In the second preferred 

embodiment the debit request includes the encrypted sensitive information. The 
debit request is received by the CFISP 14a which decrypts the sensitive 
information and transmits the completely decrypted ACH or ECP debit request 3c 
to the customer's financial institution 16. 
1 5 The third preferred embodiment of the present invention combines the 

capabilities of the first and second prefenred embodiments. Figure 4 enables a 
customer modem 10 to transmit customer payment instructions 1 via the Internet 
11 to a merchant terminal 12. The merchant terminal 12 adds the merchant's 
payment instructions and transmits the data message containing both the customer 
20 and merchant payment instructions 2a (hereafter "data message") over the Internet 
1 1 to the MFISP server 14b. The MFISP 14b receives the data message 2a and 
reformats it into a deposit message 2b that is recognizable and readable by the 
merchant's financial institution 18. This reformatting is necessary since the 
original data message 2a received by the MFISP is in an Internet or other public 
25 access network format, unreadable by the merchant's financial institution 18. The 
MFISP transmits the deposit message over a closed communication channel 
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5 (CCC) or similar network thai is established as a network for carrying deposit 
messages to financial institutions. 

The merchant's financial institution server 18 decrypts all but the encrypted 
sensitive information and reads the data message and begins settlement procedures 
vdih the customer's financial institution 16 over the automated clearing house 
10 (ACH) network or electronic check processing (ECP) network using an ACH or 
ECP (hereafter "ACH") debit request 3a. The debit request includes the encrypted 
sensitive information. The debit request is received by the CFISP 14a which 
decrypts the sensitive information and transmits the completely decrypted ACH or 
ECP debit request 3c to the customer's financial institution 16. In an alternative 
15 embodiment, the MFISP 14b performs the composition of the ACH or ECP debit 
request and transmits it to the customer's financial institution 16. As is shovm, the 
CFISP 14a intercepts the ACH or ECP debit request in order to deqrypl the 
encrypted sensitive information. 

In describing a fourth preferred embodiment of the present invention^ the 
20 following hypothetical situation illustrates the need for such a system and method 
A customer, not limited to either an individual or a business^ has discovered the 
Internet to be an appropriate forum in which to locate prospective merchandise 
and/or services and merchants for the customer's purchasing needs. Instead of 
being limited to either using credit card informaticm via e-mail; Hypertext Mark^ 
25 up Language (HTML) pages; or telephonically vrith all of the debit and credit 
delays associated therewith; or even more cumbersome, having to actually go to 
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the merchant's location and make the purchase in person, the customer desires to 
access the customer s accounts with the customer's flnancial institution on-line 
and in real-time to satisfy payment to the merchant. 

The customer's financial institution, utilizing the method and system of a 
fourth preferred embodiment of the present invention, is capable of offering this 
service to the customer through a CFISP without the need for installation of 
equipment or software at the customer's financial institution and vsathout the need 
to reveal to the customer, the use of the service provider. In fact, in practice, the 
presence of the service provider is unknovm to either the customer or the 
merchant. The customer and the merchant both believe that the customer's 
financial institution is performing all of the steps in the transaction. 
Consequently, the customer's financial institution increases its marketability with 
the ability to offer demanded Internet payment services without incurring the costs 
associated with implementing institution- wide hardware and software. 

The fourth preferred embodiment is illustrated in Figure 5, wherein, the 
customer modem 10 sends customer payment instructions 1 over tl^ Internet 1 1 to a 
merchant's Internet terminal 12. The merchant's tennina] 12 attaches the merchant's 
payment instructions and forms a data message having both the customer's and the 
merchant's payment instructions 2a. The data message 2a is transniitted over the 
Internet to the customer's financial institution server 16 but is first intercepted by 
the CFISP 14a where it is reformatted into a recognizable and readable on-line 
debit message (e.g., ATM) 2b and then forwarded on to the customer's financial 
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5 institution server 16 over a CCG. This reformatting is necessary since the original 
data message 2a received by the CFISP is in an Internet or other public access 
network format, unreadable by the customer's fmancial institution 16. The 
customer's financial institution 16 checks the customer's chosen payment account 
to verify that the funds are available and sends an on-line, real-time notification 4a 
10 to the merchant 12 over the CCC The CFISP 14a receives the notification 

authorizing or denying the debit over the CCC and reformats the notification 4b 
for transmittal over the Internet 11 to the merchant terminal 12. The customer's 
financial institution or the CFISP, either simultaneous with the notification 
message or at some later time, will send a guaranteed ACH credit 3b to the 
15 merchant's fmancial institution server 18 in order to facilitate settlement of the 
transaction. In the case where the CFISP sends the ACH credit, the CFISP is 
necessarily a financial institution as opposed to being strictly a service provider. 

In a fifth preferred embodiment of the present invention, similar to the 
secOTid prefeued embodiment of the present invention, the merchant's financial 
20 institution does not choose to have the merchant's account number, or oth^ 

sofisitive information necessary for carrying out the payment transaction, presented 
to the customer or anyone other participant, other the merchant's own financial 
instituticHi, in any readable fwrn. But, in the fifth preferred embodiment, the 
merchant's financial institution does not have the necessary decrypticm tools for 
25 reading the encrypted, sensitive information. 
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5 In Figure 6, utilizing a processor with a modem 10, the customer sends 

encrypted customer payment instiuclions 1 over the Internet 11 to a merchant's 
Internet terminal 12. The merchant's terminal 12 attaches the merchant's payment 
instructions and forms a data message having both the customer's and ihe mierchant's 
payment instructions 2. The data message 2 is transmitted over the Internet 1 1 to 
10 the customer's financial institution server 16 where the server sends a notification 
4 of authorization or denial of debit from the customer's selected payment account 
to the merchant over the Internet 11. The customer's financial institution 16 also 
decrypts all but the merchant's encrypted sensitive information and reads the data 
message and begins settlement procedures with the merchant's financial institution 
15 18 by issuing an ACH credit 3b, In the fifth preferred embodiment the ACH credit 
includes the encrypted sensitive information. The ACH credit is received by the 
MFISP 14b which decrypts the sensitive information and transmits the completely 
decrypted ACH credit 3d to the merchant's financial institution 18: 

A sixth prefOTCd embodiment of the present invention combines the fourth 
20 and fifth preferred embodiments of the present invention, wherein each financial 
institutiMi utilizes a service provide. 

In Figure 7, the customer modem 10 sends customer payment instructions 1 
over the Internet 11 to a merchant's Internet terminal 12. The merchant's terminal 12 
attaches the merchant's payment instructions and forms a data message having both 
25 the customer's and the merchant's payment instructions 2a. Specific portions of the 
merchant's payment instructions are encrypted so as not to be readable by any party 
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5 other than the merchant's financial institution. The data message 2a is transmitted 
over the Internet to the customer's financial institution server 16 but is first 
intercepted by the CFISP 14a where it is reformatted into a recognizable and 
readable on-line debit message (e.g., ATM) 2b and then forwarded on to the 
customer's financial institution server 16 over a CCC. This refonmatting is 
1 0 necessary since the original data message 2a received by the CFISP is in an 
Internet or other public access network format, unreadable by the customer's 
financial institution 16. The customer's financial institution 16 checks the 
customer's chosen payment account to verify that the funds are available and 
sends an on-line, real-time notification 4a to the merchant 12 over the CCC. The 
15 CFISP 14a receives the notification authorizing or denying the debit over the CCC 
and reformats the notificatim 4b for transmittal over the Internet 1 1 to the 
merchant terminal 12. 

Simultaneously, or soon thereafter, the customer's financial institution or 
the CFISP, decrypts all but the marchant's mcrypted sensitive information and 
20 reads the data message and begins settlement procedures with the merchant's 
financial institution 18 by issuing an ACH credit 3b. In the sixth preferred 
embodimmt the ACH credit includes the encrypted sensitive information. The 
ACH credit is received by the MFISP 14b which decrypts the sensitive 
information and transmits the completely decrypted ACH credit 3d to the 
25 merchant's financial institution 18. 
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5 A seventh preferred ernbodiment of the present invenlion addresses the on- 

line pavmenl situation wherein the customer seeks to minimize the amount of 
customer payment and identification information that is available to any entity 
other than the customer's financial institution. In this particular embodiment, the 
customer's bank is not capable, without a service provider, of receiving and 
1 0 imderstanding the customer's Internet payment request. 

Referring to Figure 8, the customer modem 10 directs the customer payment 
insinictions 1 a to the customer's financial institution 16 via the Internet 1 1 . The 
CFISP 14a then reformats the customer payment instructions into a CCC debit 
message lb that is readable by the customer's financial institution 16 and transmits 
15 the CCC debit message over a CCC. The customer's financial institution receives the 
CCC debit message and either authorizes or denies the debit. Notification of this 
authorization (or denial as the case may be) plus the remaining or encrypted customer 
payment instructioiis 5a (hereafter "notification+'^ is sent via the CCC to the 
merchant terminal 12 but is actually first received by the CFISP 14a where the 
20 notification+ 5a is reformatted into an Internet format notificatioiH^ message 5b. The 
CFISP 14a then transmits Internet notification+ message 5b to the merchant terminal 
12 via the Internet 11. 

An alternative sub-part to the seventh embodiment, has the CFISP 14a sending 
the encrypted customer payment instructions 1 a directly to the merchant terminal 12 
25 either with notification of authorization 5b or without, depending on the relationship 
established between the CFISP 14a and the customer's financial institution. 
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The eighth through thirteenth embodiments of the present invention, 
include the system components and steps recited with reference to the seventh 
preferred embodimeni. Consequently, these will not be repeated in the description 
of these additional embodiments. 

In the eighth preferred embodiment of Figure 9, upon receipt of the 
Internet notirjcation+ message 5b, the merchant's teniiinal 12 attaches the 
merchant's payment instructions and forms a data message having both the 
customer's payment instructions {if any) and the merchant's payment instructions 2. 
The data message 2 is transmitted over the Internet to the merchant's financial 
institution server 18 where the server reads the data message and begins settlement 
procedures with the customer's fmancial institution 16 by issuing an ACH or ECP 
debit request 3a. 

The customer's fmancial institution retrieves the customer's payment 
instructions or decrypts the customers portion of the payment instructions inchidcd in 
the ACH or ECP debit request from the merchant's fmancial institution in order to 

finalize settlement. 

In the ninth preferred embodiment of Figure 10, upc«i receipt of the 
notification+ 5b the merchant terminal 12 adds the merchants paymrat instructions 
and transmits the data message containing both the customer and merchant 
payment instructions 2a over the Internet 1 1 to the MFISP server 14b. The 
MFISP 14b receives the data message 2a and refwmats it into a deposit rnessage 
2b that is recognizable and readable by the merchant's fmancial institution 18. 
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5 This reformatting is necessary since the original data message 2a received by the 
MFISP is in an Internet or other public access network format, unreadable by the 
merchant's financial institution 18. The MFISP transmits the deposit message 
over a closed communication channel (CCC) or similar network which is 
established as a network for carrying deposit messages to financial institutions. 
10 The MFISP may batch two or more payment insuuctions in one deposit message. 

The merchant's financial instimtion 18 receives and processes the deposit 
message 2b and initiates settlement with the customer's financial institution server 
16 over the traditional ACH or ECP network or similar settlement channel with an 
ACH or ECP debit request 3a. Alternatively, the MFISP is capable of initiating 
1 5 the ACH or ECP debit request 3a as opposed to the merchant's financial 
institution. 

The customer's financial institution retrieves the customer's payment 
instructions or decrypts the customers portion of the payment instructions included in 
the ACH or ECP debit request from the merchant's financial institution in order to 

20 finalize settlement. 

In the tenth preferred embodiment of Figure 1 1, the customer*s financial 
institution 16 does not have the decryption capabilities necessary to deoypt the 
encrypted customer payment instructions within the ACH or ECP debit request 3a 
sent by the merchant's financial instituticm 18. Consequently, the ACH or ECP 

25 debit request 3a is received by the CFISP 14a and the encrypted customer payment 
instructions are decrypted by the CFISP 14a fomiing a completely readable ACH 
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or ECP debit request 3c prior to being forwarded to the cxislomer's financial 
institution 16. 

In the eleventh preferred embodiment of Figure 12, the components and 
functions of the ninth and tenth embodiments are combined. Upon receipt of the 
notification+ 5b the merchant terminal 12 adds the merchant's payment 
instructions and transmits the data message containing both the customer aiid 
merchant payment instructions 2a over the Internet 1 1 to the MFISP server 14b. 
The MFISP 14b receives the data message 2a and reformats it into a deposit 
message 2b that is recognizable and readable by the merchant's financial 
institution 18. This reformatting is necessary since the original data message 2a 
received by the MFISP is in an Internet or other public access network format^ 
unreadable by the merchant's financial institution 18. The MFISP transmits the 
deposit message over a closed communication channel (CCC) or similar network 
which is established as a network for carrying deposit messages to financial 
ir)Stitutions. 

The merchant's financial institution 18 receives and processes the deposit 
message 2b and initiates settlement vwth the customer's fmancial mstitution server 
16 over the traditional ACH or ECP network or similar settlement channel with an 
ACH or ECP debit request 3a. Alternatively, the MFISP is capable of initiating 
the ACH or ECP debit request 3a as opposed to the merchant's financial 
institution. 
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5 Since the customer's financial institution 16 does not have the decryption 

capabilities necessary to decrypt the encrypted customer payment instructions 
within the ACH or ECP debit request 3a sent by the merchant's financial 
institution 18. The ACH or ECP debit request 3a is received by the CFISP 14a 
and the encrypted customer payment instructions are decrypted by the CFISP 14a 
10 forming a completely readable ACH or ECP debit request 3c prior to being 
forwarded to the customer's financial institution 16. 

In the twelfth embodiment of Figure 13, upon receipt of the notification+ 
5b the merchant's terminal 12 attaches the merchant's payment instructions and forms 
a data message having both the custcmer's and the merchant's payment instructions 
15 2a. The data message 2a is transmitted over the Internet to the customer's financial 
institution server 16 but is first intercepted by the CFISP 14a where it is 
reformatted into a recognizable and readable on-line debit message (e.g., ATM) 2b 
and then forwarded on to the customer's financial institution server 16 over a 
CCC. This reformatting is necessary since the original data message 2a received 
20 by the CFISP is in an Internet or other public access network format, unreadable 
by the customer's financial institution 16. The customer's financial institution 
servCT 16 initiates settlement by issuing an ACH credit 3b to the merchant's 
financial instituticm server 18. 

In the thirtCOTth embodiment of Figure 14, the components and fiincfions 
25 of the twelfth embodiment are incorporated therein, with the addition component 
of a MFISP 14b. The ACH credit 3b issued by the customer's financial institution 
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5 - 16 is actually received by the MFISP 14b wherein encrypted merchant payment 
instructions are decrypted prior and a completed ACH credit 3d is the transmitted 
to the merchant's financial institution 18. 

In all of the preferred embodiments, standard public key/private key 
encryption and other security mechanisms are employed to secure the 
10 transmissions of the payment instructions- When the service providers receive 
incoming messages they perform a variety of security checks including validating 
the digital c»tificates to identify the sender and checking the digital signatures to 
ensure the integrity of the messages. The service providers then decrypt the 
received messages to retrieve information and re-encrypt them, when appropriate, 
1 5 prior to transmission to their respective financial institutions. 

As discussed jweviously, one possible source of the security mechanisms 
(e.g. keys, certificates, signature capability) and enabling software used in 
practicing the embodiments of the invention is the service providers. The service 
|HX>vid^ in addition to issuing the security mechanisms and the software, also 
20 provide maintoiance and update service with respect to these components of the 
system. In order to provide a maximum level of encryption security, there may be 
periodic changes of the keys used in the public/private key system. Similarly, 
there may be software upgrades and customer or merchant information changes 
(e.g., new accounts, name changes, address changes). Much of this responsibility 
25 stems from the contractual relationship established between the financial 

instinjtion and the financial institution's service jwovider. Along these same lines, 
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5 in addition to the security, software, formatting, and routing services performed by 
the service provider, the service providers also offer transaction tracking services, 
investigatory services, and Internet server operation services. 

In each of the preferred embodiments discussed above, the service 
providers are invisible and unknown to the customer and the merchant at all times. 
1 0 Similarly, those employing the service providers, namely, the customer's fmancial 
institution and the merchant's financial institution do not utilize the identity of the 
service provider in performing their respective functions during the transaction. 
Consequently, although they are employing the services of the service providers, 
the transaction requests received by their respective servers from the service 
15 providers are indistinguishable from any other U^ansaction requests received 
without the aid of a service provider. 

With reference to each of the preferred embodiments, there is no limitation 
on the type of customer debit accounts or merchant deposit accounts which may be 
accessed in practicing any of the embodiments of the invention. For example, the 
20 debit accounts could include checking, savings, money market, mutual fund, or 
any comparable account wherein the customer's financial institution recognizes 
real-time debiting procedures. Merchant deposit accounts include checking, 
savings, mwiey market, mutual fund, mortgage, loan, credit card, or any 
comparable account wherein the merchant's financial institution recognizes 
25 crediting procedures. 
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A significant advantage offered by the prefenred embodiments offering an 
on-line, real-time debit authorization notification to the merchant is that the 
merchant understands an authorization notification (as opposed to a denial 
notification) from the service provider to mean that the merchant will receive an 
ACH credit, within one or two business days, for the amount of the purchase. 
Consequently, the merchant then releases the goods and/or services immediately 
upon receipt of the authorization notification or informs the customer of the 
immediate release/rejection of the order (e.g., shipment procedures will be 
immediately initiated). All of this appears to the customer and the merchant to 
have occurred on-line and in real-time. 

For the preferred embodiments where there is no on-line, real-time debit 
authorization notification, the merchant may choose to delay the release of the 
goods and/or services until a reasonable time period has elapsed and the merchant 
has not received notification that the debit has been returned. Of course, there are 
many idiosyncratic factors which play into when the release of goods takes place, 
such as the past course of dealings between the parties^ the type of goods and/or 
services, the purchase price and the identity of the parties. The higher the risk and 
the greater the loss, the less likely there will be a release without some notification 
' of debit authorizaticHi. 

Similarly, the while the merchant's financial institution must credit the 
merchant's account upon notification of the transacticMi, this does not translate into 
immediate availability of ftinds equaling the credit to the merchant. The 
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merchants financial institution will consider a variety of factors and financial 
institution standards in detennining when to make the fiinds available for use by 
the merchant, including merchant identity, past course of dealings, and amount of 
the credit. 

Further, for the applicable preferred embodiments discussed above, the 
payment software, depending on the preferences of the issuee (e.g., customer, 
merchant, customer's fmancial institution, merchant's financial institution) might 
include or require many conceivable types of data prior to initiating the on-line 
payment processes. The various types of data required for completion of an on- 
line payment transaction are capable of being retrieved and/or added at many 
different stages in the transaction process by different parties to the transaction. 
Further there are multiple levels of encryption security mechanisms which may be 
employed to mask the information from various parties during the transaction 
process. One skilled in the art recognizes the many possible scenarios and 
variations. 

* * ■ 

The preferred embodiments of the present invention provide for on-line and 
in some cases real-time paymwit transactions over a public access network such as 
the Internet, without the need for hardware other than standard processors, 
modems, and servers. With the abolition of the need for magnetic stripe cards or 
smart cards in performing an oiHiine debit payromt transactions comes the 
abolition of the need for appropriate card readers and a significant reduction in 
cost. 
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One skilled in the art will recognize the many additional variations and 
embodiments which are contemplated by the invention. For example, in 
alternative embodiments, the CFISP could function as the merchant's financial 
institution or the MFISP could function as the customer's financial institution. In 
these embodiments, Ihe service providers are referred lo as correspondent financial 
institutions since the service providers also offer banking services. Depending on 
the specific embodiment, the correspondent financial institution would be able to 
either authorize and debit the customers account upon receipt of the data message 
if acting in the MFISP/customer financial institution capacity or credit the 
merchant's selected deposit account upon receipt of debit authorization if acting in 
the CFISP/merchant financial institution capacity. 

Another variation that is inherent to each of tlie preferred embodiments is 
anticipated multiplicity of parties. For example, the CFISP and the MFISP could 
handle as many Internet payment requests from as many customers as the 
customers' financial institution services and to whom the appropriate enabling 
software has been issued Likewise, the MFISP will process as many merchant 
payment requests as it receives for the merchants' financial institution, limited 
only by the number of merchants who utilize the merchant financial institution and 
are in possession of the enabling software. 

This multiplicity variation also applies to multiple financial institutions 
utilizing a single service provider, each financial institution accepting payment 
transactions via the service provider for multiple customers or merchants. 
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FiifiaUy, a single service provider could be simultaneously acting as a 

CFISP and a MFISP. 

There are additional software inclusions that do not directly affect the 
actual formation process of the data messages. The issued software anticipates 
multiple users within, for example, a single family or business. For added security 
and privacy, the software is configured to accommodate multiple passwords for 
multiple users. Similarly, the service provider may personalize the software with 
multiple digital certificates for multiple users. By way of example, a husband and 
wife may hold multiple accounts with a customer's financial institution, some joint 
accotmts, some individual accoimts. Both may wish to utilize the Internet or 
comparable public access network for making purchases and both may desire to 
pay over the IntCTnet with funds from accounts held at the customer's financial 
institution. Further, for a large payment amount, one or both of the husband and 
wife may desire to split the payment between multiple accoimls. The service 
provide will issue digital certificates to both individuals which mclude their 
respective account information and vrill require separate passwords or personal 
identificatifm numbm (PINs) prior to attaching them to a data message. 

Ahhou^ the invention has been described with reference to these preferred 
embodiments, other embodiments can achieve the same results. Variatiwis and 
modificatims of the present invention will be apparent to cmc skilled in the art and 
the present disclosure is intended to cover ail such modifications and equivalents. 
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I Claim: 

1 1. A method for processing a financial transaction involving a first 

2 financial institution, a second financial institution, and a service provider 

3 comprising: 

4 receiving a first transaction message at the service provider over a 

5 first network; 

6 formatting the first transaction message at the service provider into a 

7 second transaction message for acceptance by the second financial institution; and 

m 

8 transmitting the second transaction message from the service 

9 provider to the sectmd financial institution. 

1 2. A method according to claim 1 , wherein the first transaction 

2 message comprises a debit request and encrypted data. 

1 3. A method according to claim 1, wherein the first transaction 

2 message comprises a credit and encrypted data 

1 4. A method according to claim 3, wherein the encrypted data is a 

2 dd>it account nvunber. 
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5. A method according to claim 3, wherein Ihe encrypted data is a 
deposit account number. 

6. A method according to claim 1, wherein the first network is selected 
from the group consisting of an automated clearing house (ACH) network and an 
electronic check processing (EC?) network. 

7. A method according to claim 1 , wherein the second transaction 
2 message comprises a debit request and decrypted data. 



1 8. A method according to claim 1 , wherein the second transaction 

2 message comprises a credit and decrypted data. 

1 9. A method according to claim 7, wherein the decrypted data is a 

2 debit account number. 

1 1 0. A method acc€»rdmg to claim 8, i«*erein the decrypted data is a 

2 deposit account number. 

1 1 1 . A system for processing a financial transaction comprising: 

2 a first network for transmitting a first data message; 
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a first server for receiving the first data message, decrypting the first 
data message, and reformatting the first data message into a second data message: 

a second network for transmitting the second data message; and 
a second server for receiving the second data message. 

1 2. A system according to claim 1 1 , wherein the first data message 
includes payment instructions. 

1 3. A system according to claim 1 2, wherein the payment instructions 

2 include at least a debit account identifier, financial institution identifier, and a 

3 deposit accotmt identifier. 

1 1 4. A system according to claim 1 1, wherein the first network is a 

2 public access network. 

1 1 5. A system according to claim 14, wherein the public access network 

2 is the Internet. 

1 1 6. A system according to claim 1 1 , wherein the second netwwk is a 

2 closed commtmication channel. 
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1 7. A system according to claim 1 1 , wherein the second data message 
includes reformatted payment instructions. 



1 8. A system according to claim 1 2, wherein the reformatted payment 
instructions include at least a debit account identifier, a first financial institution 
identifier, and a deposit account identifier. 



t a 



1 9. A method according to claim 1 2, wherein the first data message is in 
first network format and the second data message is in a second network format. 



1 20. A method according to claim 1 2, wherein the first data message is 

2 an electronic mail (e-mail) message. 



1 2 1 . A method according to claim 1 2, wherein the first data message is a 

2 hypertext markup language (HTML) page. 



1 22. A method according to claim 1 2, wherein the seccmd data message 

2 is formatted as a debit request. 



1 23. A method according to claim 12, wherein the second data message 

2 is formatted as a credit request. 
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1 24. A method for processing a financial iransaclion comprising: 

2 transmitting a first data message over a first network; 

3 receiving the first data message, decrypting the first data message, 

4 and reformatting the first data message into a second data message at a first server; 

5 transmitting the second data message over a second network; and 

6 receiving the second data message at a second server from the 

7 second network. 

1 25. A method according to claim 24, wherein the first data message is in 

2 a first network format and the second data message is in a second network format 

1 26. A method according to claim 24, wherein the first data message is an 

2 electronic mail (e-mail) message. 

1 27. A method according to claim 24, wherein the first data message is a 

2 hypertext marktip language (HTML) page. 

1 28. A method according to claim 24, wherein the second data message 

2 is formatted as a debit request. 

1 29. A method according to claim 24, wherein the second data message 

2 is formatted as a credit request. 
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1 30. A method for processing a financial transaction involving a first 

2 user, a first user's financial institution, a second user, a second user*s financial 

3 inslitulion, and a service provider over multiple networks, comprising: 

4 issuing to the first user i) software for directing steps of the financial 



5 transaction and ii) at least one certificate for identifying the first user to the service 

6 provider, wherein at least one of i) or ii) contains information about the first user's 

7 financial institution; 



8 receiving at the service provider from the second user via a first network at 

9 least the first user's at least one certificate, the second user's fmancial transaction 

1 0 information, and an encrypted first data message requesting performance of a 

1 1 financial transaction, wherein the financial transaction includes debiting an 

12 account of the first user held at the first user's financial institution; 

13 verifying an identity of the first user at the service provider via the first 

14 user's at least one certificate; 

1 5 decrypting at the service provider the first data message to facilitate 

1 6 performing the financial transaction; 

17 formatting at the service provider at least a first portion of the first data 

1 8 messa^ to resemble a financial transaction that is recognizable and readable by 

19 the first user's financial institution; 

20 encrypting by the service provider the fonnatted portion of the first data 

21 message; 
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22 forwarding from the service provider the encrypted formatted portion of the 

23 first data message to the first user's financial institution via a second network 

24 requesting authorization to perform the financial transaction; 

25 receiving at the service provider via the second network from the first 

26 user's fmancial institution a response to the request for authorization to perform 

27 the financial transaction; and 

28 transmitting from the service provider to the second user via the first 

29 network a response to the request for authorization to perform the financial 

30 transaction. 

1 3 L A inethod according to claim 30, wherein the formatted portion of 

2 the first data message that is recognizable and readable by the fu^st user's financial 

3 institution is a debit message. 

1 32. A method according to claim 30, wherein the response to the request 

2 for authwization to perform the financial transaction is selected from the group 

3 consisting of : 

4 ( 1 ) a denial of authorization to perfonn the financial transaction, 

5 (2) an authorization to perform the financial transactim, and 

6 (3) a request for further information. 
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33. A method according to claim 30, wherein the firsi notification of the 
response lo the request for authorization to perform the financial transaction is 
contained in a second data message. 

34. A method according to claim 30, wherein the second network is a 
closed communication channel. 

35. A method according to claim 34, wherein the closed commimication 
channel transmits debit requests. 

1 36. A method according to claim 34, wherein the closed communication 

2 channel is the Internet. 

1 37. A method according to claim 30, further comprising: 

2 reformatting at the service provider the response to the request for 

3 authorization to perform the fmancial transaction prior to transmitting the response 

4 to the secmd usor. 

1 38. A method acccnrding to claim 30, fiirther comprising: 

2 initiating settlement of accounts by the service provider betweai the 

3 first user's financial institution and the second user's fmancial institution via a 
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third data message over a third network, wherein Ihe third data message is based 
on at least a second portion of the first data message. 



39. A method according to claim 38, wherein the third network is an 
automated clearing house (ACH) network. 

40. A method according to claim 38, wherein the third data message is a 

credit. 

41. A method according to claim 40, wherein the credit is an automated 
2 clearing house (ACH) credit. 

1 42. A method according to claim 3 1 , further comprising: 

2 initialing settlement of accounts by the first user's financial 

3 institution between the first user's financial institution and the second user's 

4 financial institution via a third data message over a third network, wherein the 

5 third data message is based on at least a portion of the debit message. 

1 43. A method according to claim 42, wherein the third network is an 

2 automated clearing house (ACH) networic 
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44. A method according to claim 42, wherein the third data message is a 



2 credit. 

1 45. A method according to claim 44, wherein the credit is an automated 

2 clearing house (ACH) credit. 

1 46. A method according to claim 30, wherein the first network is a 

2 piiblic access network. 

1 47. A method according to claim 46, wherein the public access network 

2 is the Internet. 

1 48. A method according to claim 30, wherein the first data message is 

2 an electronic mail (e-mail) message. 

1 49. A method according to claim 30, wherein the first data message is a 

2 hypertext mark-up language (HTML) page- 

1 50. A method for processing a financial transaction involving a first . 

2 user, a first user's financial institution, a second usct, a second user's financial 

3 institution, and a service jMrovider over muhiple networks, comfHising: 
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4 issuing to the first user i) software for directing steps of the financial 

5 transaction and ii) at least one certificate for identifying the first user to the service 

6 provider, wherein at least one of i) or ii) contains information about the first user's 

7 financial institution; 

8 receiving at the service provider from the first user via a first network at 

9 least the first user's at least one certificate, the second user's financial transaction 

10 information, and an encrypted first data message requesting performance of a 

1 1 financial transaction, wherein the financial transaction includes crediting an 

12 account of the first user held at the first user's financial institution; 

1 3 verifying the identity of the first user at the service provider via the first 

1 4 uscr*s at least one certificate; 

1 5 decrypting at the service provider the first data message to facilitate 

16 performing the financial transaction; 

1 7 formatting at the service provider at least a first portion of the first data 

1 8 message to resemble a fmancial transaction thai is recognizable and readable by 

19 the first user*s financial institution; 

20 encrypting by the service provider the formatted pc»lion of the first data 

21 message; and 

22 forwarding from the service provider the encrypted formatted portion of the 

23 first data message to the first user's financid instituticHi via a second nelwcM*. 
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1 5 1 . A method according to claim 50, wherein ihe formatted portion of 

2 the first data message that is recognizable and readable by the first user*s financial 

3 institution is a credit message. 

- ■ 

1 52. A method according to claim 50, wherein the first network is a 

2 public access network. 

1 53. A method according to claim 52, wherein the public access network 

2 is the Internet/ 

1 54. A method according to claim 50, wherein the first data message is 

2 an electronic mail (e-mail) message. 

1 55. A method according to claim 50, wherein the first data message is a 

2 hypertext mark-up language (HTML) page. 

1 56. A method according to claim 50, wherein the second network is a 

2 closed conununication charmel. 

1 57. A method according to claim 56, wherein the closed conununication 

2 channel transmits credit messages. 

SUBSTITUTE SHEET (RULE 26) 



WO0W22559 PCTAUS99/19627 

-45- 

1 58. A method according lo claim 56, wherein the closed communication 

.2 channel is the Internet- 

■ • ' 

1 59. A method according to claim 50, further comprising: 

2 initiating settlement of accounts by the service provider between the 

3 first user's financial institution and the second user's financial institution via a 

4 third data message over a third network, wherein the third data message is based 

5 on at least a second portion of the first data message. 

1 60. A method accwding to claim 59, wherein the third network is an 

2 automated clearing bouse (ACH) network. 

1 6 1 . A method according to claim 59, wherein the third network is an 

2 electronic check processing (ECP) network. 

1 62. A method according to claim 59. wherein the third data message is a 

2 debit request. 

1 63. A method according to claim 62, wherein the debit request is an 

2 ' automated clearing house (ACH) debit request. 
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64. A method according to claim 62, wherein the debit request is an 
electronic check processing (ECP) debit request. 

65. A method according to claim 5 1 , further comprising: 

■ 

initiating settlement of accounts by the first user's financial 
institution between the first user's financial institution and the second user's 
financial institution via a third data message over a third network, wherein the 
third data message is based on at least a portion of the credit message. 

66. A method according to claun 65, whwein the third network is an 
automated clearing house (ACH) nctwork. 

1 67. A method according to claim 65, wherein the third network is an 

2 electronic check processing (ECP) network. 

1 68. A method according to claim 65, vAercin the third data message is a 

2 debit reqiiesL 

1 69. A method according to claim 68, wherein the debit request is an 

2 automated clearing house (ACH) debit request 
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] . 70. A method according to claim 68, wherein the debit request is an 

2 electronic check processing (ECP) debit request. 
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